This patent application claims the priority of the following two U.S. provisional patent applications, Ser. No. 60/063,164 entitled xe2x80x9cFEATURES OF A MOBILE DEVICE AND ASSOCIATED COMPUTERxe2x80x9d, filed on Oct. 24, 1997 and Ser. No. 60/064,986 entitled xe2x80x9cFEATURES OF A MOBILE DEVICE AND ASSOCIATED COMPUTERxe2x80x9d, filed on Nov. 7, 1997.
Reference is hereby made to the following co-pending U.S. patent applications which are hereby incorporated by reference:
Ser. No. 09/058,613, filed on even date herewith, entitled xe2x80x9cELECTRONIC MAIL OBJECT SYNCHRONIZATION BETWEEN A DESKTOP COMPUTER AND MOBILE DEVICExe2x80x9d; and
Ser. No. 09/058,528, filed on even date herewith, entitled xe2x80x9cSYSTEM AND METHOD FOR INTERACTION BETWEEN A DESKTOP COMPUTER AND MULTIPLE MOBILE DEVICExe2x80x9d, all of which are assigned to same assignee as the present invention.
Mobile devices are small electronic computing devices often referred to as personal digital assistants. One such mobile device is sold under the trade name Handheld PC (or xe2x80x9cH/PCxe2x80x9d) based on a Windows CE brand operating system provided by Microsoft Corporation of Redmond, Wash. While a wide variety of computing tasks and applications can be performed by such mobile devices, personal information managers (PIMs) are particularly well suited to mobile devices.
PIMs typically comprise applications which enable the user of the mobile device to better manage scheduling and communications, and other such tasks. Some commonly available PIMs include scheduling and calendar programs, task lists, address books, and electronic mail (e-mail) programs. Some commonly commercially available PIMs are sold under the brand names Microsoft Schedule+ and Microsoft Outlook and are commercially available from Microsoft Corporation of Redmond, Wash. For purposes of this discussion, PIMs shall also include separate electronic mail applications, such as that available under the brand name Microsoft Exchange.
It is also common for mobile devices to be used in conjunction with a desktop computer. For example, the user of a mobile device may also have access to, and use, a desktop computer at work, at home, or both. A user may typically run the same types of PIMs on both the desktop computer and the mobile device (although the particular versions of the PIMs may be somewhat different from the desktop computer to the mobile device). Thus, it is quite advantageous for the mobile device to be designed to be couplable to the desktop computer to exchange information with, and share information with, the desktop computer.
The user may also typically make changes to the PIMs both on the mobile device, and at the desktop. Therefore, it is advantageous for the PIMs on both the mobile device and the desktop to contain the most up-to-date information, regardless of whether recent changes to the PIMs have been made on the mobile device or the desktop computer. The process of coupling the mobile device with the desktop computer, and integrating the information stored by the PIMs on the mobile device and the desktop computer such that the two contain the same updated information is referred to as synchronization.
Conventional PIMs which support electronic calendaring and scheduling features (collectively referred to as a scheduler, or as a scheduling application) are traditionally supported on desktop computers. Such PIMs provide the ability of the user to schedule a meeting request for one or more desired attendees.
In order to generate a meeting request, the user typically interacts with the scheduling application through a user interface. The user interface provides the user with a plurality of selectable options to parameterize the meeting request. For example, the user interface typically allows the user to pick a date and time (and often a place) on which the meeting is to be held. The user interface also typically allows the user to select a group of attendees that the user wishes to attend the meeting, to enter some textual description of the meeting, and to specify whether the meeting is for only a single date, or is a recurring meeting (i.e., whether the meeting is to occur only on one date, the 15th of every month, the first Monday of every month, every Monday, etc.).
Based on this information, the scheduling application creates an object which is representative of the meeting and enters it on the user""s calendar as an appointment. Such objects are typically defined by a number of properties, some of which are defined by the user input information which the user provides while generating the meeting request. The meeting object also contains a critical time stamp (UTC) which is updated whenever a critical change is made to the meeting object, such as changes to the start or end date or time, changes in the location, etc.
Since other people are identified as attendees, the appointment entered on the calendar is viewed as a meeting and the scheduling application typically calls methods exposed by an electronic mail application in accordance with messaging application programming interfaces (MAPI), or other APIs which are a set of well documented, published interfaces commercially available from the Microsoft Corporation of Redmond, Wash.
In response, the electronic mail application creates another object (an electronic mail meeting request object) indicative of the meeting request and the electronic mail application (or suitable transport) formats this electronic mail meeting request object into a well defined electronic mail message suitable for transmission. In doing so, the critical time stamp from the meeting object is also placed in the electronic mail meeting request object. The electronic mail application then interacts with a specified transport and transports the electronic mail meeting request object to a network which routes it to the designated attendees. In doing so, the electronic mail application typically accesses an address book stored in a database to obtain the fully qualified electronic mail address for the attendees. This is also typically done by calling MAPI or other suitable API methods associated with the database storing the address book. The generation of the meeting object and the creation of the electronic mail meeting request object will be referred to herein collectively as creating a meeting request.
The potential attendees then typically respond to the meeting request. In doing so, the originator""s critical time stamp is sent back (unmodified) along with the response. The response also includes a recipient critical time stamp and an indication of the recipient""s response (e.g., accept, decline, tentative, etc.). The recipient critical time stamp is updated by the recipient (potential attendee) whenever a critical change is made by the recipient. This allows the user to reliably order receipt of multiple versions of the same meeting (e.g., where the originator changes the time, date or location of the meeting such that multiple meeting requests are generated). It also allows the originator to reliably order receipt of responses and ensure that each response correlates to the most recent version of the meeting.
The response is then transmitted back to the originator (e.g., the sending computer). The electronic mail application and scheduling application on the originator then typically process the response (or responses) accordingly. For example, the originator stores, for each recipient (or potential attendee) the recipient critical time stamp in a table along with each recipient""s response code (which is indicative of the accept, decline, tentative response). The two commercially available PIMs identified above (the Microsoft Schedule+ and Microsoft Outlook brand PIMs) are examples of PIMs which support the features discussed above.
Meeting cancellations, and exceptions to recurring meeting must also be handled. For example, the PIMs may allow scheduled meetings to be cancelled, and allow a variety of exceptions to a recurring meeting pattern.
Scheduling of meeting requests as described above has, to date, only been supported by desktop computers or laptop computers which are fitted with a hard disk drive or other high capacity memory mechanisms, or by low intelligence terminals which are permanently attached to a server or other similar computer which, itself, contains a high capacity storage device. The ability to schedule a meeting request from a mobile device is simply unavailable. While some current mobile devices are provided with PIMs that allow the user to view meeting requests, and to view meetings which have already been scheduled, current mobile devices do not allow the user to generate a meeting request from the mobile device itself.
A number of significant obstacles present themselves when attempting to provide the user with the capability of generating a meeting request from a mobile device. Meeting cancellations and exceptions to recurring meetings must be handled. Also, a significant problem arises with respect to the possibility of transmitting duplicate meeting requests. While duplicate meeting requests as described below may not necessarily be created with all PIMs, they do present a potential problem which must be considered. For example, if the user of the mobile device were able to generate a meeting request, a meeting object would first be entered on the calendar of the mobile device. The electronic mail application on the mobile device would then create a corresponding electronic mail meeting request object. The next time the mobile device was synchronized with the desktop computer, the meeting object would be synchronized with the calendar object store on the desktop computer and the electronic mail meeting request object would be synchronized to the desktop outbox. The desktop computer, would recognize the electronic mail meeting request object in its outbox, format it for transmission, and transmit it over the network. Further, synchronizing the meeting object to the calendar of the desktop computer may result in another electronic mail meeting request object being created and transmitted by the desktop computer. This would result in duplicate electronic mail meeting request objects being created (one by the mobile device, and one by the desktop computer after synchronization) and transmitted. Under that scenario, potential attendees would receive two or more meeting requests, and may respond to both. This would create duplicate responses to what was intended to be a single meeting request.
A similar problem may occur if a meeting request were generated in a conventional manner (on a desktop computer) for instance, and was then synchronized to a mobile device having the capability of generating and transmitting meeting requests. The meeting object on the desktop calendar would be synchronized to the calendar of the mobile device. The mobile device might then recognize the meeting object synchronized from the desktop, and create an electronic mail meeting request object and attempt to transmit the object. This would result in substantially the same problemxe2x80x94duplicate meeting requests and duplicate responses for what was intended to be a single meeting request.
Further, if the user of the mobile device coupled the mobile device for synchronization with more than one desktop computer (e.g., a home computer and work computer, if the mobile device were provided with this capability) the same problem would result. In that instance, and using conventional architecture, both desktop computers would synchronize with, and recognize, the meeting object and the electronic mail meeting request object from the mobile device. The desktop computers would both potentially create additional electronic mail meeting request objects and transmit them to the potential attendees. Again, this would result in many different meeting requests and responses being transmitted for what was intended to be only a single meeting request.
In addition, if mobile devices were provided with the capability of being connected directly to one another, and communicating with one another, without going through a desktop or similar computer, the meeting request could be generated by one mobile device, responded to by another mobile device, and scheduled on both mobile devices. However, the next time the first mobile device is synchronized with the desktop computer, that computer might again recognize the meeting object synchronized from the calendar of the mobile device, create another electronic mail meeting request object and transmit the electronic mail meeting request object. Thus, a significant problem potentially exists with respect to the generation of multiple meeting requests.
Of course, similar problems also result from critical changes to the meeting object on either the desktop computer or the mobile device. This will cause unwanted duplicate electronic mail meeting requests in a similar fashion.
Additional problems also present themselves simply by the fact that conventional mobile devices have a memory capacity which is significantly less than that of a desktop computer or similar computer. Thus, problems arise with respect to storing address books on the mobile device itself which contain the fully qualified electronic mail address of all potential attendees.
Further obstacles present themselves because many desktop computers on which the meeting request must be processed have different scheduling applications. Therefore, the meeting request generated by the mobile device may be incompatible with scheduling applications which it encounters.
In addition, localization of meeting requests can present a problem. For instance, in some localities, it is conventional, when writing a date, to place the month first, the day second and the year third. In other localities, other orders are conventional. Further, a textual description which describes the meeting and which accompanies the meeting request, may need to be rearranged to conform to local convention. Also, meeting requests can be generated in one time zone and transmitted to recipients in other time zones. This can tend to be confusing.
The present invention addresses some or all of these obstacles.
The present invention includes a mobile device which provides the user with the ability to schedule a meeting request from the mobile device itself. The mobile device creates an object representative of the meeting request and assigns the object a global identification number which uniquely identifies the object to other devices which encounter the object. In this way, other devices which encounter the meeting request are capable of identifying it as a unique meeting request in order to alleviate the problem of duplicate meeting request transmissions.
In accordance with another preferred feature of the present invention, an electronic mail application or calendar application on the mobile device obtains a fully qualified electronic mail address for the potential attendees from an abridged address book or directory stored on the mobile device itself. This alleviates problems associated with the storage capacity of the mobile device.
In accordance with another preferred embodiment of the present invention, the mobile device creates the meeting object and the electronic mail meeting request object using a set of properties which are supported by a plurality of PIMs that may receive the objects. This provides compatibility with an increased number of devices which are likely to encounter the objects.
In accordance with yet another preferred feature of the present invention, localizers implement a plurality of templates on the mobile device which are used in formatting the properties of the objects associated with the meeting request. A data stream representative of the meeting request is parsed by the mobile device and placed in pre-defined fields in the appropriate templates so that the text viewed by the user of the mobile device more closely conforms to local convention. In addition, time zone information is also included in one embodiment.